home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19961006-19970104 / 000115_news@columbia.edu _Mon Nov 4 13:16:05 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id NAA09908 for <kermit.misc@watsun.cc.columbia.edu>; Mon, 4 Nov 1996 13:16:04 -0500 (EST)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id NAA18843 for kermit.misc@watsun; Mon, 4 Nov 1996 13:16:03 -0500 (EST)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Question about kermit transfer rates.
  8. Date: 4 Nov 1996 18:15:41 GMT
  9. Organization: Columbia University
  10. Lines: 45
  11. Message-ID: <55lbsd$e77@apakabar.cc.columbia.edu>
  12. References: <Pine.ULT.3.93.961031223333.29154A-100000@coho.halcyon.com> <55d3ai$9gk@apakabar.cc.columbia.edu> <55l68b$oge@bug.rahul.net>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <55l68b$oge@bug.rahul.net>, Clarence Dold  <dold@rahul.net> wrote:
  16. : Frank da Cruz (fdc@watsun.cc.columbia.edu) wrote:
  17. : : On a V.32bis/V.42/V.42bis connection, RTS/CTS flow control, no parity, 
  18. : : 57600 bps interface speed:
  19. : :
  20. : :   Typical text files:        3500 cps (characters per second)
  21. : :   Uncompressed binary files: 2400 cps (e.g. PC KERMIT.EXE)
  22. : :   Compressed files:          1600 cps (e.g. ZIP files)
  23. : :
  24. : : Double those figures for V.34.  For details, see the Kermit FAQ:
  25. : 
  26. : I agree with Frank on the figures for a 14.4 connection, but I can't
  27. : get double the rates on a 33.6 connection...  
  28. : I am seeing 2600 for MSKermit.exe to Unix C-Kermit, and 2800+ on Unix to
  29. : Unix gzip files.  The text files vary widely, but /etc/termcap
  30. : transfers at about 6000cps unix to unix.
  31. : 
  32. The computer(s) or the connection itself might be a bottleneck.  Are you
  33. sure, for example, that the two modems really negotiated a 33600bps
  34. connection?  And if they did, that both computers are fast enough to keep
  35. up with it (hint -- watch the RTS and CTS lights on the modem: if the local
  36. computer is flow-controlling the modem, that means the local computer is
  37. not keeping up; of course the same thing might be happening on the other end,
  38. but you can't see it).
  39.  
  40. : This is without the prefix tuning that might be possible for some
  41. : connections.  I work through a Telebit Netblazer modem server, and I can't
  42. : find a set of prefix characters to make it happy, so I've left it as is.
  43. : On another connection that was direct to a Unix box, I could gain some
  44. : speed with modifying the prefixing set, but not enough for me to bother
  45. : with.
  46. : 
  47. You can gain up to 26% throughput by unprefixing.  Usually you only have to
  48. prefix somewhere between 3 and 8 characters, so depending on the nature of
  49. the data, you can get a significant boost from this.
  50.  
  51. : I also run 38400 rather than 57600, as I don't find my small boxes capable
  52. : of handling 57600 properly.  Actually, that was derived empirically with
  53. : a 14.4 modem at one end, and 28.8 at the other.  I might rerun some
  54. : experimentation now that I have a pair of 33.3 modems.
  55. : 
  56. In that case, you should see better results if your computer(s) can keep up,
  57. because obviously the 14400 bps modem would be a bottleneck.
  58.  
  59. - Frank